Motion analysis

From WiiLi.org

Wiiリモコンとヌンチャクコントローラは３軸加速度計(ASXL330)を内蔵しています。それはプレーヤによって与えられた瞬間的な力を、任意の単位で返します。静止時、上方向に重力があります。ですから自由落下時にはおよそ０の値を返します。３次元空間では６つの自由な角度を持ちます。３軸上の平行移動と３つの回転方向(前に倒れる→pitch、転がる→roll、振る→yaw)は右回りの値で示す。

１.較正

加速度に反応するセンサーがおおかた線形で、かつチップが基板上の正確な位置にあると仮定するならば、Wiiリモコンの構成は3段階でできます。必要とする力に関するデータは、平らに置いたときの位置と、レベルテーブルです。

上にＡボタンがある水平状態を：

ＩＲセンサーを下にテーブルに載せて、そして拡張ポートを表面を上に(?)：

その面を標準に、そして左側を上にしたときを(?)：

このとき、それぞれの１軸には重力がかかり、その他の２軸がゼロ点を示しています、

これによって各軸のゼロ点を推測することができます。

センサーから数値を読み始めると、その較正値は

この較正値はＧ＝１の場所での値です。

あるリモコンではこれらの定数は次のようになりました。

7

10

9.5

27

27

27

３つの手順の較正に従うと、それが必要とするテーブルはユーザーにとって面倒かもしれません。

ですから、正確でない点順も好ましいのかもしれません。上記の例にもとついて、センサーの利得は(基本的にはサイズはＧ）リモコンのゼロへのオフセットよりももっと近いのでは、と推測します（おそらく誤っていますが）

その場合の必要値は、リモコンを測定するために一時的に静止状態させ、そのときの０オフセットを３軸に一度適用すればよいのです。

実際のところこのような手順は平らな面を持たないヌンチャクセンサーの唯一の較正方法かもしれません。

2.傾斜位置

リモコンが加速していないのならば、そのリモコンの傾きは重力を使って直接計算できます。初めにセンサーからの加速信号を－１～１ｇになるように（上記の較正を見て）変換してください。すると、

pitch = asin(ax/1 g)

roll = asin(ay/1 g)

これらの方程式に注意してください

・手の動きによってリモコンに加速度が生じている場合、正常化された加速度値は１以上、－１未満になります。そしてASINはこれに定まりません。確認する方法のひとつとして、３個の加速度のベクトル和がｇの近くにあるとき、リモコンが加速していないのを見ることです。

・それが垂直な方向から重力に向きを変えた時、加速度計が位置に対してより敏感でなくなることを注意してください。これによりリモコンを標準的な持ち方で持ったとき、ｚ軸は加速度計の位置検出はあまり役立ちません。しかしリモコンがその位置から傾けられると、他の２軸に加えてｚ軸を使うことが必要とされます。

・リモコンが加速しているならば、最新の値と比較して傾きの変化を取得し、加速度の２つの相和が必要となります。

・     揺れ(Yaw)の値を得るためにはIRセンサーを使わなければなりません。揺れはリモコンがセンサーバーの方から向きを変えたとき、そのときのセンサーバーのポイント速度、センサーバーとの距離（センサーバーの中の赤外線ポイントの間の距離から推定）から推定することが可能です。そして加速度計の全体を記録します。しかしながら、その遠すぎるとエラーが出させるでしょう。

３.力

すべての既知のWiiリモコンは地球の表面で使われているので、プレーヤーが加速度をかけていないときでも、それにかかる力は一定です。（地球上にいるという予備知識なしでは、この力はプレーヤによる加速度と見分けられません。一般相対性理論のすばらしさを思わせてくれるものです。）

すべての回転の軸が、"モーションセンサー"または"回転が線形ではなく加速すること"に十分に近いと仮定します。(すなわち、レバーアームがありません）

加速度 a(t)はセンサーによって計測されます（リモコンの加速度は真実ではない）。

Rは回転行列で、リビングルームの枠をリモコンのフレームまでに変換します。

そしてaはリビングルームの枠でのリモコンの実際の加速度です。

回転行列は３つのオイラーの角度の法則によりパラメーター化されます。またリモコンの線形加速は３つのコンポーネントを持っています。

６つのダイナミックな変数とともにしますが３つしか観測できないので劣決定系します。

しかしながら、見せかけを単純化することで、いくらかの情報を抜粋することができます。

３.１　純粋な回転。

リモコンが加速していないとみなすならば（最適な通常使用状況で静的なとき）モーションセンサーは直接どちらが"上"かを示します。

これがオイラーの角度の法則のうちの２つを引き出します。しかしリビングルームフレーム（コントローラーが水平なとき、Yawと一致する）のｚ軸周りの角度ではないです。

この情報の不足は、３つの加速度計でスクリーン上のポインターをコントロールする難しさの理由の一つです。

ユーザーのためにポインターの水平運動を示すもっとも自然な運動は、コントローラーをｚ軸周りに回転させることです。

しかしながら２つの角度は、様々な用途のためには十分な規制です。

"上"のベクトルはセンサーの応答が直接使われることができる、または角度に分解します。

（公式をここにおいてください）

３.２　回転しないとき

リモコンが回転しない（）のは、運動方程式がそのままの唯一の条件です。

このようにのよい推定を得るためにはの初期条件がさらに必要です。前のセクションであがっていた方法のようにリモコンが静止しているとき、この情報を得ることができます。

３．３　ジャーク

加速の変化率に面白く名付けられた語、それがジャークです（ほとんど使われていない）

ジャークは"センサーによって記録された力を時間による導関数で示したもがリモコンを上に示す"ことを称します。回転をもまた角速度を含む意味で同じです。少しだと仮定するならば、回転と線形加速を引き出すことをできます。

運動が始まる前に"上"方向は分かっていますから、これは
です。

運動を通して、水平なリモコン上のジャークは重力の方向への小さいです。

それから時間による力の構成要素の導関数は、ユーザーがコントローラーを回転することによって起因する上方向を現在と推定すれば垂直です。これは次の時間ステップのために、上方向の推定を更新することを許します。各時間ステップでは、力センサーの現在のの推定から引くことによって、リモコンの線形加速を手に入れることもできます。実質的に常微分方程式のセットの中にあります。（注.数学をここでチェックしてください。注意します）

この技術に関する主な問題は"上"に関する予想の蓄積によるエラーです。これはユーザーがコントローラーを一定の線形動作を「テレビ」「彼らの対戦相手」「彼ら自身」を負傷させずに保持しそうもないですし、力がG=1.0から最新のに近いと合計を報告したときに時間を見つけることができます。

４．ジェスチャー

最初に想像するよりも多い状況のために、それは正確な回転やリビングルーム参照フレームで線形加速を引き出すことは完全に不必要です。そのこととして記述されました。Wiiのための多くのゲームはあらかじめ定義された運動パターンを通してリモコンの問題命令を使うことの力を示しました。たとえば、剣攻撃をシミュレートするためにリモコンを切り払ったり、投げ縄のような円でリモコンの周りに激しく当たります。これらのジェスチャーのような命令を運動データはいくらかの曖昧なパターンマッチングを必要とします。これはコントローラーの小さな回転にもまた鈍感です。

AiLiveはWii開発者が動的に利用できるように、彼らが身体的にコントローラーを望ましいパターンを何度か動かすことで異なる動作を認識する訓練をします。

詳細な情報は彼らの白書にあります。

（その他に発表されたこの類の運動認識への研究はここで歓迎されます。）

５.引用

Introduction to using accelerometers (A presentation from Analog
Devices): http://www.analog.com/Analog_Root/static/library/techArticles/mems/sensor971.pdf

Some of the data sheets for Analog Devices accelerometers have hints
for how to analyze the output: http://www.analog.com/en/subCat/0,2879,764%255F800%255F0%255F%255F0%255F,00.html